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ABSTRACT 


This report is an overview of the complete electronics 
package which controls the Mars roving vehicle. It is meant to 
provide a broad overview of the systems which are part of that 
package and discusses some software debugging tools. The specific 
functions of the different electronic subsystems are described, 
with the microprocessor-based systems discussed more fully because 
they are not discussed in other reports in their present form. 
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PART J 


INTRODUCTION 

The Mara rover was developed at Rensselaer for the purpose 
of investigating the problems associated with an autonomous roving 
vehicle. If it were necessary to man sadly control a rover on Mars 
from Earth, the radio transmission time between the two planets would 
significantly limit its performance* Therefore it is essential that 
whatever control systems and computer programs used as a means of 
controlling the vehicle have the capability of operating without human 
intervention for extended periods of time. To this end, our rover has 
Incorporated cctf.rol elements through the use of a computer which is 
at a fixed location as well as electronic systems on the vehicle it- 
self with the Intent that on a real Mars exploration mission the fixed 
computer would either be on the Martian surface or else orbiting the 
planet so that transmission time could be neglected. 

As of 1975, the fixed computer used was a Varlan 6201 lo- 
cated in the basement of the Sage Laboratory building. It was used to 
run the control algorithms which analyzed data from the rover. On 
board the 1975 rover was a predominantly analog control electronics 
package which provided feedback control of the vehicle's wheel speeds 
and formed the telemetry data stream sent to the fixed computer. This 
system had some inherent problems, however. First, the wheels often 
fought with each other when they were driving the vehicle since no 
provision was made for detecting if one or more of them might actually 
be dragging. Second, since the electronics was mostly analog cir- 
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cuitry, the drift vhich occurred between calibration* was a problem, 
a* was me rather complex calibration procedure Itself. Third, new 
ideas concerning control systems couldn't be experimented with be- 
cause the basic system was realised totally in hardware. 

It was decided that the control system should be redesigned 
in an attempt to alleviate these problems. The fixed computer which 
is presently used is a Prime 750 located on the second floor of the 
Jonsson Engineering Canter (JEC) in the Image Processing Laboratory 
(IPL). The 750 was chosen for the new system because it has more 
speed than the Variar and the programs which run on it could be written 
in Fortran whereas before they were written in Varian assembler 
language. The use of Fortran has made it possible to develop a large 
part of the software on the IBM 3033 and subsequently transfer it to 
the Prime. Also, new software people joining the project are more 
likely to understand Fortran than assembler, thus simplifying the task 
of understanding the present Prime software. 

The on-board control electronics package has been replaced 
by a completely digital system which is controlled by a Motorola 
M6800 microprocessor. The micro has the capability to monitor all 
wheel speeds independently and correct for both speed and torque varia- 
tions on them. The feedback control for this purpose is digital in 
nature under the present system, so that once it has been calibrated, 
it should not be necessary to repeat the calibration orocedures for 
some time, possibly never. Changes in the methods emploved in the 
digital control system can be made easily due to the fact that such 
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changes would moat probably ba made In Che program running in the 
microprocessor. 

The laser hazard detection system Installed on the 1975 
rover was a single- lacer/ single detector system which had the nroblem 
of missing a significant number of the reflections from terrain In 
front of the vehicle. The new laser system Is a multl-laser/mul el- 
detector system which has Che capability of firing up to 32 times the 
number of laser shots per scan as the old system as well as having 
better chances of receiving returns because of the fact that it has 
20 detectors instead of only one. as did the 1975 version. 

This report deals with the present control systems used on 
the rover as well as any related software tools and control programs 
which are applicable in this regard. 


PART 2 


SIMPLIFIED OVERVIEW 

A block diagram of tha systems for controlling the rover 
and gathering data from It Is shown In Fig. 2.0.1. Key elements are 
tha laser mast, telemetry system, microprocessor, command link and 
the Prime computer. The laser mast gathers d°.*-a concerning objects 
in front of the vehicle. This data is transmitted to the Prime by 
the telemetry system along with vehicle data so that the programs 
running on that machine can determine what course of action to take, 
for example, stopping the vehicle if It encounters a ravine or other 
hazardous terrain feature. The microprocessor must interpret com- 
mands sent from the Prime and also control the vehicle's wheel 
speeds. It can also display data about the state of the vehicle on 
a terminal attached to a port on the microprocessor itself. The pos- 
sibility exists of sending commands to the laser mast from the Prime 
by having the microprocessor relay those commands, for example, 
it is possible to select the scan patterns used by the mast by send- 
ing the appropriate mast command. Should manual control of the 
vehicle be desired, a portable command box can replace the Prime 
computer as the source of commands. The General Purpose Interface 
Board (GPIB) is installed in the mainframe of the Prime computer and 
provides the circuitry for getting data into the Prime's memory where 
programs can use it as well as for sending commands to the vehicle. 
Through the use of radio frequency (RF) links, it is possible for the 
vehicle to operate approximately k mile from the fixed computer in 
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Che Engineering Center. 

Because of che face Chat operation of the control system 
as a whole relies upon complex software and hardware interactions* 
testing the system provides numerous opportunities for exercising 
the GPIB. To that end* it has proven useful to have several programs 
which do nothing more than display data which the telemetry system is 
transmitting, even though this data is presented in its raw form. 
Still others exist which simulate commands which the path selection 
and navigation routines might send to the vehicle in an attempt to 
make sure that each command given to the microprocessor has the de- 
sired effect. 


PART 3 


MICROPROCESSOR CONTROL OF THE ROVER 

The microprocessor on board the rover is housed in a card 
cage mounted in the rear of the vehicle's payload section. Its lo- 
cation is shown in Fig. 3,0.1. This card cage contains all of the 
electronics with which the mic r ^processor Interfaces except the 
laser mast electronics, which are contained in a separate card cage 
mounted on the mast itself. Multi-conductor ribbon cables connect 
the microprocessor to these other electronic subsystems. Fig. 3.0.2 
shows the card cage ribbon cable assembly. 

The microprocessor functions to interpret commands from the 
Prime computer or the portable command box, maintain proper wheel 
speeds to result in a given vehicle speed and steering angle, display 
vehicle data on a terminal attached to one of its serial ports, for- 
mat telemetry data for its own use, and interpret information con- 
cerning the torque on each wheel. Details of the microprocessor hard- 
ware and software are given in References 1 and 8. 

When all of the circuit boards are installed in the rear 
vehicle card cage, the microprocessor is configured as shown in 
Table 3.0.1. Note that the locations from $D400 through $DFFF can be 
selected as corresponding to either Erasable Programmable Read-Onlv 
Memory (EPROM) or Random Access Memory (RAM) . The dollar sign in 
this instance is used to indicate a hexadecimal address within the 
microprocessor system. All EPROM sockets are located on the micro- 
processor board except those for the A30 and A31 EPROMs, which are 
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Table 3.0.1 Configuration of the Microprocessor System. 


A. Input/Output Ports 

2 Peripheral Interface Adapters (PIAs) 

PIA #1 (loc. $8004) - interfaces to EPROM programmer and tele- 

metry system. 

PIA ft 2 (loc. $8020) - Interfaces to EPROM programmer, laser mast 

and telemetry system. 

2 Asyncronous Communications Interface Adapters (ACIAs) 

ACIA #1 (loc. $8008) - interfaces to terminal attached to the 

microprocessor. 

ACIA #2 (loc. $8010) - interfaces to the command link receiver. 

B. Ram^Soace 

Propulsion system scratchpad memory 
MINIBUG* monitor scratchpad memory 
Additional RAM on RAM board 

Ram shored with the telemetry system 

C. 

2 Free EPROM sockets (loc. $D400 - $ 

(loc. $0800 - $ 

Input/Output Software (I0S) EPROM 
(supplied by Motorola with the mi 

(loc. $DC00 - $ 

MINIBUG EPROM 

(supplied by Motorola with the mi 

(loc. $E000 - $ 

"A30" monitor EPROM 

(developed in the rover lab to burn EPROMs) 

(loc. $9000 - $93FF) 

A31" text EPROM 

(contains the text for messages printed out by the A30 monitor) 

(loc. $9400 - $97FF) 

*The MINIBUG is a Motorola monitor program which starts running on 
the microprocessor when it is powered up. 


(loc. $00 
(loc. $A000 
(loc. $B000 
(loc. $D000 
(loc. $C400 


$FF) 

$A07F) 

$BFFF) 

$DFFF) 

$C4FF) 


D7FF) 

DBFF) 

cro) 

DFFF) 


cro) 

E3FF) 
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located on the RAM board. Since the software for the propulsion 
system requires approximately 3K bytes (3072 locations) of EPROM 
space (three type 2708 EPROMs) , the Input/Output Software (IOS) 

EPROM should be removed and the sockets corresponding to the con- 
tinuous memory locations from $D400 through $DFFF should be used 
for the EPROMs containing that software. It should be noted that 
the Peripheral Interface Adapters (PIAs) do not interface to more 
than one device at a time, but may be connected to each of the de- 
vices they interface with via ribbon cables. 

3.1 Program Organization 

The program which runs in the M6800 was written to a large 
extent a year ago and is discussed at length in the report by 
J. Turner (Reference 1). The current version of the software is 
scored in the User File Directory (UFD) named <USERS3>MARS>GRAHAM> 
WHEELS. GD on the IPL’s Prime 750 and should be on the backup tape 
which contains all the files used by the rover project. Also in- 
cluded in that UFD is a copy of the Motorola assembler and the emu- 
lator for the M6800 as well as the program *DNL0AD which allows users 
to dox<mload programs from the Prime to the microprocessor. There are 
also several command files which are useful for assembling and re- 
constructing the file TAPE and LISTING. The former contains the 
M6800 machine code and the latter contains the listing of all of the 
subroutines which are part of the propulsion system software. 

Another UFD named <USERS3>MARS>GRAHAM>SIM68 is used to 
store the copies of the M6800 assembler and emulator created when they 
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were being developed to run on the Prime instead of the IBM 3033* 

The assembler was furnished by Prof. J. McDonald, while the emulator 
has bean modified from the standard Motorola version by Including 
the capability to insert breakpoints in programs being emulated. 

There is also a copy of this modified emulator which ran on the IBM 
3033. Note that SIM68 contains the source listing of the above 
programs, except the assembler, as well as some of the compiled code. 

The propulsion system software itself consists of several 
subroutines which are stored in EPROMs and implement the functions 
described in the introduction to this chapter. A control loop whose 
function is to call the subroutines is cooled from one of the 
EPROMs to the system's RAM during system initialization. Since the 
subroutine calls are in RAM, it is possible to bypass any of these 
subroutines by using a terminal attached to the micro to replace that 
subroutine call with "no operation" (NOP) instructions. After the 
propulsion system software has initialized itself, then typing any 
characters on that terminal will return the user to the MINIBUG 
monitor on the microprocessor, thus enabling him to change any memory 
locations or load additional programs before executing that software 
again. Only a single character must be typed to break the control loop. 

3.2 Command Decoding 

The list of valid commands which the microprocessor can in- 
terpret is shown in Table 3.2.1. These are decoded in a subroutine 
named CMDDEC, which has replaced Turner's NEWCMD subroutine. In this 
new routine, it is possible to decode both single-byte eight-bit and 
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Table 3.2*1 Valid Commands Decoded by the Microprocessor. 
Command Name Command Code (Hex) 


ONE WHEEL DRIVE 

Off 


08 


Left Rear 

OC 


Right Rear 

OD 


Left Front 

OE 


Right Front 

OF 

STEERING: (LEFT) 

-90.0° 


47 


-67.5° 


46 


-56.25° 


45 


-45.0° 


44 


-33.75° 


43 


-22.5° 


42 


-11.25° 


41 


0.0° 


40 

(RIGHT) 

0.0° 


48 


11.25° 


49 


22.5° 


4A 


33.75° 


4B 


45.0° 


4C 


56.25° 


4D 


67.5° 


4E 


90.0 


4F 

MAIN DRIVE 

Forward 

Full 

53 


Forward 

Ttoo- thirds 

52 


Forward 

One- third 

51 


Stop 


50 


Stop 


54 


Reverse 

One third 

55 


Reverse 

TWo- thirds 

56 


Reverse 

Full 

57 

FRONT WHEEL DRIVE 

: Forward 


7A 


Stop 


78 


Reverse 


7B 

MISC. COMMANDS: 

Gyro Init 

77 


Vehicle 

Reset 

7F 


Display On 

76 


Display Off 

74 


Override Terrain Compensation 

10 


Restore 

Terrain Compensation 

11-1? 

TWO- BYTE STEERING 


8X nn 


where nn Is the twos-complement steering 
angle in steering units (STU) . 


* 


TWO-BYTE MAST COMMAND 

where nnn are bits sent to the laser mast 


9n nn 
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two-byte eight-bit commends , whereas on the 1975 rover only seven-bit 
single-byte commands could be decoded. One reason for changing to 
eight-bit commands was that the most significant bit (MSB) now indi- 
cates whether the command is one or two bytes long. A zero in the 
MSB signifies a single-byte command* while a one in the MSB signifies 
a two-byte command and the microprocessor interprets the next command 
byte which it receives as the second half of that command. This for- 
mat keeps the commands used with the 1975 rover compatible with those 
used with the 1980 vehicle. This was desirable so that time-consuming 
hardware modifications would not have to be made to the portable 
command box used for manual control of the vehicle. 

The first type of two-byte command is the two-byte steering 
command. This exists so that it is possible to choose any steering 
angle from -90 to +90 degrees and not be limited by the fixed steering 
angles provided by the single-byte steering commands. The first byte 
of this command contains the hexadecimal characters 8X» where X indi- 
cates four bits which are "don’t-cares.” The second byte contains the 
desired steering angle in steering units in txro's- complement form. 

To convert from degrees to steering units, multiply by 1.421875. This 
conversion factor results from representing an angle between -90 and +90 
degrees as a two’s complaint binary number between -127 and +127. The 
Prime computer generates two-byte steering commands but the portable 
command box still sends single-byte steering commands. 

The second form of two-byte command which is also sent ex- 
clusively by the Prime is the laser mast command, the format of which 
is shown in Fig. 3.2.1. The actions which the mast takes when it 


FIRST BYTE 
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* 

mast command bits 

A. Center of Scan Azimuth Command 
Meat Command Blea » 0000 


Second byte of the command contains the 
azimuth angle , 0 through 255 » of the 
center-of-scan. 


B. Scan Pattem/laaer Enable Command 
Mast Command Bits ■* 0001 

SECOND BYTE 



1 - laser enabled 
0 - laser disabled 



00 - first azimuth pattern 

01 - second azimuth pattern 

10 - third azimuth pattern 

11 - fourth azimuth pattern 


00 

01 

10 

11 


first elevation pattern 
second elevation pattern 
third elevation pattern 
fourth elevation pattern 


C. Scanning Speed Command 
Mast Command Bits * 0010 


SECOND BYTE 


00-0 scans/sec, 

01 - 0.25 scans/sec. 

10 - 0.50 scans/sec. 

11 - 1.0 scans/sec. 


Fig. 3.2.1 


Format of Laser Mast Commands 
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receive* on* of Ch**« commands ar* described in Section 4.1. 

3.3 Wheel Speed Control 

It is desirable to control the speed of each wheel indi- 
vidually from two points of view. The first is to take into account 
the desired steeerlng angle of the vehicle and change the wheel 
speeds accordingly. Since the front axle of the 1980 rover no longer 
has a steering motor as the 1975 version did, it relies on differences 
in the front wheel speeds as the only means for steering the vehicle. 
The subroutine which corrects the wheel speeds for an appropriate 
steering angle is named STEERCOR. Its present form is essentially 
that described in Reference 1. 

The second reeson for controlling the wheel speeds is to 
attempt to keep them from working against one another and wasting 
battery power. A subroutine named TERCOR monitors switches on the 
drive train of each wheel which measures whether the torque on that 
wheel is positive or negative. If a wheel is found to be dragging 
(negative torque), then adjustments are made in that wheel's speed 
until it does not drag. This is done by increasing a parameter called 
the set speed for that wheel. Each time the microprocessor detects 
that the wheel is dragging, it will increase the set speed by 38 speed 
units (SPU) , which corresponds to a velocity of 0.15 m/sec. in the 
forward direction. 

Once the set speed parameters for each wheel are generated 
by STEERCOR and TERCOR, they are digitally low pass filtered by the 
subroutine FILTER. These filtered set speeds are used bv the propor- 
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Clonal speed controller subroutine CONTROL to generate the drive 
signals which are fed to the motor driver circuitry for each wheel. 

CONTROL calculates the difference between the filtered set 
speed and the actual wheel speed for each wheel, multiplies this by 
the appropriate controller gain, and adds or subtracts the resulting 
change In the drive signal to the present drive signal. It checks 
Chat the maximum values for negative and positive wheel speeds are 
not exceeded In the process of this calculation, l.ie controller 
gains are switch-selectable parameters, the switches for which are 
located on the motor speed board in the microprocessor card cage. 

Fig. 3.3.1 shows the location of these switches as well as those 
used to set the filter parameters of the digital filter. It is good 
practice to set the filter parameters and controller gains with the 
vehicle's wheels off the ground and the display routine described in 
Section 3.4 running in order to monitor the numerical values of 
those parameters. 

Each of the switches In Fig. 3.3.1 is divided into two 
sections of four bits each. After reading them, the subroutine 
GETDAT calculates the controller gains, filter parameters and the 
three velocities at whic* the vehicle can travel as shown in Table 
3.3.1. These three velocities are the full, two-thirds and one-third 
speeds, calculated in speed units (SPU) . The circuitry which inter- 
faces the microprocessor to the drive motors has been changed since 
Turner's original, design and is discussed in Reference 8. Suggested 
switch settings are discussed in Reference 1. 



5 11 SPEGD1 

5 12 SPEED2 

5 21 SPEED3 

5 22 LFGAIN 

5 31 RFGAIN 

5 32 RRGAIN 

5 41 LRGAIN 

5 42 FILPA2 , FILPAR 
S 51 DELTV1 


Fig. 3.3.1 Switch Location on Motor Speed Board for 
Vehicle Control Parameters. 
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Table 3.3.1 Formulas for Switch-Selectable Vehicle Control 
Parameters used by Subroutine GETDAT. 


Parameter Formula Comments 


Speodl 

25+4*!)S 11 

'One-third' speed (SPU) 

Speed2 

25+4*DS 12 

•Two-third' speed (SPU) 

Speed3 

25+4*DS 01 

'Full' speed (SPU) 

LFGAIN 

4*DS V , 

a* «> 

Left front controller gain 

P-FGAIN 

4*DS 3 i 

Right front controller gain 

REGAIN 

4*DS 32 

Right rear controller gain 

LRGAIN 

4*DS . . 
41 

Left rear controller gain 

FILPA2 

0.875+08^*0. 00078125 

Filter time constant 

FILPAR 

1-FILPA2 

Filter gain 

DKLTV1 

4*DS 5 i 

Maximum turn rate 


Note: I s the setting of the switch for the selected 

parameter as shown in Fig. 3.1.1 
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3.4 Display of Vehicle Parameters 

The subroutine DISPLAY will display certain information 
about the state of the vehicle on a terminal connected to the micro- 
processor. The mlcropressor responds to commands which can cause 
it to enable or disable this display. While any type of terminal 
may be used for this purpose, a CRT type running at 9600 baud should 
give the best performance as it provides a fairly fast update of the 
screen, the format of which is shown in Fig. 3.4.1. The amount of 
data displayed by this subroutine has been increased since Turner's 
original version to display almost all of the dynamic variables used 
by the microprocessor. In the figure, numerical data which is 
printed out is shown as 'nnn.' The steering angle is printed in 
degrees and the wheel speeds are printed in mm/sec as the linear 
gpeed of the center of each wheel. 

3.5 Vehicle Data Acquisition 

The microprocessor relies on the telemetry system to gather 
the vehicle data it needs. The vehicle data is fed through an 
analog multiplexer to an analog- to-digital converter. The telemetry 
system makes this digitized analog data, along with any digital 
vehicle data, available to the microprocessor by storing the data in 
a Random Access Memory (RAM) which is shared by the telemetry system 
and the microprocessor. 

Currently the microprocessor has control over whc has read 
and write access to that RAM; thus it has the responsibility of 
allowing the telemetry system to write to it. The software in use 


DESIRED STEERS + nnn DEGREES 

ACTUAL STEER: +nnn DEGREES 
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Fig. 3.4.1 Microprocessor Display of Vehicle Parameters. 
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at Che present time grants this access to the telemetry system for 
the majority of the time that it Is running. The microprocessor 
will rescind that access only while it is reading the RAM and 
writing to it for its own purposes, a process which happens only 
once each time through the control loop and which takes 100-120 usee, 
every 10 msec. Thus the telemetry system is denied access to that 
RAM for approximately 1% of the time when both the microprocessor 
and telemetry system are running. 


PART 4 


LASER MAST 

The laser mast provides the means by which the Prime com- 
puter can detect objects in the vehicle's path* The mast supports 
optics and electronics which allow Its laser to fire a matrix of 
laser shots on the terrain In front of the vehicle. While It Is 
possible to 9can the terrain behind the rover, this Is not practical 
due to the range of the laser scanning system and the amount the 
vehicle extends behind the mast. Documentation on the mast control 
electronics may be found in References 3 and 6. Documentation on 
the laser and detector electronics can be found in Reference 7. 

Laser shots can be fired so as to form a straight line 
radiating outward from the mast on level ground. Each such line of 
laser shots is referred to as an azimuth because it occurs at a par- 
ticular azimuth angle with respect to a zero-degree reference directly 
ahead of the vehicle. Since there are 256 possible azimuth angles and 
the mast rotates through 360 degrees for each scan, it is possible to 
fire an azimuth of laser shots anywhere with a resolution of 1.4 
degrees. A maximum of 32 of the available 256 azimuths may be used 
in any particular scan. 

Within each azimuth it is possible to have up to 32 laser 
shots which are known as elevations because they are laser shots which 
are fired at different angles in a vertical plane which contains the 
mast. Each elevation will correspond to a spot on the terrain about 
the vehicle at a certain radial distance from the mast along that 
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azimuth angle. The resolution of elevation angles Is 0.35 degrees. 
Azimuth and elevation angles are depicted in Fig. 4.0.1. 

4.1 Electronic Mast Controller Capabilities 

The multi- laser/multi-detector (ML/MD) laser scanning sys- 
tem is controlled by an electronics package located in the mast 
electronics card cage mounted on the back of the laser mast and shown 
in Fig. 4.1.1. It was originally designed by Craij (Ref. 3) during 
the academic year 1977/78. Its present form has not changed signifi- 
cantly from the original design, except as noted in Reference 6. 

Fig. 4.1.2 shows the rotating mirror located at the top of 
the mast. This mirror is used to generate different elevation angles 
within a particular azimuth of laser shots. The speed of the mirror 
is controlled by phase-locked loop (PLL) circuitry such that it spins 
at a rate which is 24 times that of the laser mast as a whole. A 
shaft encoder is connected to the mirror and provides a pulse output 
as feedback to the PLL. The sane type of PLL and shaft encoder 
arrangement controls the speed of rotation of the entire mast. 

By sending laser mast commands from the Prime computer via 
the command link to the microprocessor on board the vehicle it is 
possible to change the scanning speeds of the laser mast. Available 
speeds are 0,, 0,25, 0.5 and 1.0 scans per second. The ratio of mast 
velocity to that of the mirror is always 1 to 24. It is also possible 
to turn off the mirror or mast drive motors independently. 

In addition to controlling the mast and mirror velocities, 
the mast controller also controls the pattern of the laser shots for 
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each scan. Both the elevation and azimuth angles at which laser shots 
occur are determined by data stored in two type 2708 EPROMs , one for 
elevation and one for azimuth angles. The system Is set up so that 
there are 256 possible elevation angles and 256 possible azimuth 
angles. Since each type 2708 EPROM has 1024 locations* the elevation 
and azimuth EPROMs can store up to four different elevation and azi- 
muth patterns each. The elevation and azimuth patterns being used can 
be selected by switches on the memory board In the mast electronics 
card cage. 

The capability exists to offset the entire set of azimuth 
angles by a fixed angle called the center-of-scan azimuth (CSA) 
angle. The CSA angle can be any of the possible azimuth angles, and 
can only be changed by a command received from the Prime. It is also 
possible to specify a fixed offset angle for elevation angles by 
setting switches on the elevation board. 

4.2 Laser Mast Commands 

The ML/MD controller electronics has been designed to accept 
several commands from the Prime computer via the command link. This 
would enable a program running on the Prime to change the dynamic 
operation of the laser mast to suit conditions which the rover might 
encounter. At the present time, there are three commands to which the 
mast electronics will respond. These are the command to change the 
CSA angle, the command to select scan patterns and enable the laser, 
and the command to specify the scanning speed of the mast. They are 
explained further in Fig. 3.2.1 and Reference 6. 
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4.3 Laser Electronics and Powtr Supply 

The later on the matt la a pulsad type and aa such can 
generate considerable nolae spikes In other electronic systems, 
particularly In the detector electronics. The power supply for 
the laser has been located In close proximity to the laser Itself 
to minimize interference generated by longer cabling. The addition 
of bypass capacitors at key points, enabling the detector electron- 
ics only at the instants when the laser fires, and other measures 
described in Reference 7, have reduced the noise to an acceptable 
level. 


4.4 Laser Data Description 

Near the base of the rotating portion of the laser mast Is 
the detector, shown in Fig. 4.3.1, which detects reflections of 
laser shots from terrain in front of the vehicle. In the figure is 
shown a 135-mm camera lens behind which is mounted a 20-element photo- 
diode array. Shown above the lens- photo- diode assembly is the de- 
tector electronics, discussed in Reference 7. 

Briefly, if a reflection occurs from the surrounding ter- 
rain within the field of view of the detector, which is about 30 
degrees, then it will fall on one or mere of the photo-diodes in the 
array. The detector electronics looks for pulses at the outputs of 
the diode array only when the laser fires and feeds its output to a 
priority network which determines the identification numbers of up 
to two of the diodes which received the reflection. Most returns 
will fall on a maximum of two diodes. Due to the design of the 
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priority network, when two or more detectors receive a return from 
a laser shot, the two Identification numbers which are generated are 
those of the highest and lowest detector which received that return. 

The laser data sent to the Prime computer has the form of 
two 16-bit words for each laser shot. First, a 16-bit address in- 
dicates which azimuth and which elevation the shot was fired at, and 
second, a 16-bit data word indicates which detector diode(s) received 
a return from that shot, if any. The 16-bit data word actually con- 
tains only 10 bits of valid information. The six most significant 
bits (MSBs) are all ones while the ten least significant bits (LSBs) 
contain two 5-bit words which are the identification numbers of the 
detector diode (s) receiving the return. Since there are only 20 
diodes in the array, these identification numbers will be between 1 
and 20 inclusive when a return is received. If no return is received, 
then the 5 LSBs of the data will be all zeros. 

Data coming from the priority network is stored in First In- 
First-Out (FIFO) memories because the mast can generate data faster 
than the telemetry system can transmit it to the Prime computer for 
analysis. The FIFOs buffer the rates at which data is generated and 
transmitted. The telemetry system gives priority to the transmission 
of laser data over transmission of vehicle data such as wheel speeds 


or gyro angles. 


PART 5 


TELEMETRY SYSTEM 

It 1 8 the function of the telemetry system to gather all 
analog and digital vehicle data as well as the digital data from 
the laser mast, make lc available to the microprocessor, and transmit 
It to the Prime computer. There Is provision for up to 16 analog and 
16 digital channels of vehicle data, the sampling of which is con- 
trollable by a type 2708 EPROM on the analog multiplexer board shown 
in Fig. 5.0.1. The analog multiplexer board is connected by ribbon 
cable to the telemetry transmitter board, shown in Fig. 5.0.2, which 
formats the telemetry data Into a serial stream for transmission to 
the Prime computer. It is the responsibility of the telemetry system 
to supply vehicle data not only to the Prime computer via the radio 
frequency (RF) telemetry link, but also to the microprocessor on 
board the vehicle via the RAM shared by both of them. The hardware 
is described by Cipolle (Reference 2). 

5.1 Data Format 

The data sent to the Prime computer is made up of a 16-bit 
address word sent with each 16-bit data word. The address word tells 
the Prime where that data word came from on the vehicle or what laser 
shot the data word corresponds to if it came from the mast. 'ach 
address word contains three interrupt bits which cause the Priie to 
perform certain operations in regard to where in the user's address 
space the data is stored. 

The three interrupts which the Prime recognizes are the 
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end-of-azimuth (EDA), end-of- vehicle (EOV) , and end-of-scan (EOS). 

An EOA interrupt is sent as part of the address for the last laser 
data word for each group of shots in an azimuth generated by the 
laser mast. An EOV interrupt is generated as part of the address 
for the last vehicle data word in a group of those words sent to 
the Prime. Finally, an EOS interrupt is generated by the laser mast 
as part of the address sent with the last laser data word of each 
scan made by the laser mast. For an explanation of the elevation/ 
azimuth scanning concept used by the mast, see Part 4. 

5.2 Vehicle and Laser Data Multiplexing 

The telemetry system must multiplex the laser data coming 
from the mast with 32 vehicle data words to be sent back to the Prime 
computer. The software which drives the interface in the mainframe 
of the Prime expects 32 vehicle words to accompany, that is imme- 
diately precede, each section of 32 laser words for each azimuth. 

Each azimuth need not contain 32 elevations and it is not necessary 
to send the vehicle data with each azimuth, but doing the latter will 
ensure that valid vehicle data are always stored with any particular 
section of laser data. Although the vehicle data words sent back to 
the Prime are 16 bits long, none of the data sent occupies all. 16 
bits except the command word echo data. 

5.3 Rate Buffering and Data Priority 

The data from both the vehicle and the laser mast are fed 
into FIFO memories in order to allow the telemetry system to transmit 
data at a different rate from that at which they are collected. The 
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absence of Che FIFOs Co buffer these two rates would have forced the 

synchronous operation of all of the systems on the vehicle which 
would have hindered design tasks considerably and greatly reduced 
their flexibility as a research tool. Data coming from the laser 
mast have priority over the vehicle data when both are present, en- 
suring that none of the data from a laser scan are lost. 

5.4 General Information 

The final serial output of the telemetry transmitter is 
generated by a Motorola chip called an Advanced Data Link Controller 
(ADLC) from the parallel data presented to it. The format of the 
transmission along with the mode of the transmitter section of the 
ADLC is controlled by type 8223 Programmable Read-Only Memories 
(PROMs) which are documented in the report by Cipolle (Reference 2). 
Each frame transmitted by the ADLC contains 16 address bits, 16 data 
bits, and 32 bits relating to starting the frame, error checking, and 
frame termination. The error checking code provides the ADLC which 
receives the data at the other end of the telemetry link with the 
capability to perform cyclic redundancy error checking on each frame. 

The telemetry receiver is constructed on a portion of the 
GPIB interface in the mainframe of the Prime computer. The output 
of the ADLC which receives the serial data is in parallel form and is 
used to fill FIFOs whose outputs are placed in the user's address space 
via direct memory access (DMA) transfer. 

While it is intended that the link from the telemetry trans- 
mitter board to the Prime be an RF link, presently it is made by co- 
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axial cable. When the RF link is implemented, cables will still 
run from the Prime to the rover lab because the radio receiver for 
the telemetry data will be located in the rover lab with its an- 
tenna on the roof of the Engineering Center. 


* 


PART 6 


COMMAND LINK 

The command link Is the means by which programs running 
on the Prime analyzing data from the rest and the vehicle may direct 
the vehicle’s actions so that it may travel toward its target while 
avoiding obstacles in its path. The command link consists of a 
Universal Asynchronous Receiver/Transmitter (UAR/T) on the GPIB 
interface which generates a serial data stream that is sent up- 
stairs to the rover lab over a multi- conductor cable. In order for 
this cable to attach to the GPIB, a short length of coaxial cable 
with a BNC connector was used in the Image Processing Lab (IPL) 
where the Prime is located. The radio frequency (RF) transmitter 
for the command link is in the rover lab and has an antenna on the 
roof of the Engineering Center. An RF receiver is located on the 
vehicle and its output is fed through demodulator circuitry to the 
microprocessor. 

6.1 Command Transmitter 

On the GPIB interface, the UAR/T converts the parallel 
data commands from the Prime into serial form. The resulting 
transistor-transistor logic (TTL) level signal is buffered and sent 
via cable to the RF transmitter In the rover lab. The RF trans- 
mitter also incorporates a Frequency Shift Keying (FSK) modulation 
circuit which converts the TTL input to an audio signal before it 
is transmitted to the rover. 
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6.2 Command Receiver 

The RF receiver on board the vehicle is mounted inside a 
small box with an antenna on It in a central position on the 
vehicle. This enclosure also contains an FSK demodulator which 
takes the received audio signal and converts it back into a TTL 
level serial data stream. The box operates on 12 VDC and contains 
the necessary voltage regulators to produce the correct voltages 
for the components inside. A speaker has been provided to monitor 
the quality of the audio signal being received by the RF receiver. 

The receiver box has two outputs which are fed to the 
Asynchronous Communications Interface Adapter (ACIA) on the micro- 
processor board which receives commands. The first output is the 
serial data output which is a TTL level signal that the ACIA can 
accept as an input. The second output i3 the loss-of-slgnal output, 
which remains in the low state as long as a strong, clean signal is 
being received. 

6.3 Portable Command Box 

If it is desirable to test the rover under manual control, 
this can be done by using the portable command box to send commands 
to the vehicle. It contains the necessary radio transmitter and 
FSK modulation circuitry to communicate with the rover in the same 
manner as the Prime does. The box has been modified to send eight- 
bit commands with even parity and one scop bit since this is the 
format of the serial data stream used for commands to the 1980 rover. 
The most significant bit (MSB) is always a zero, since the box 
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cannot transmit two-byte commands. The portable command box Is 
shown in Fig. 6.3.1. 




PART 7 


PRIME INTERFACE BOARD AND PRIME SOFTWARE 

The General Purpose Interface Board (GPIB) on the Prime 
provides a means for getting information into that computer at a 
high data rate via direct memory access (DMA) transfer. As men- 
tioned in Section 5.1, each 16-blt data word is accompanied by a 
16-bit address word which indicates where that data came from on the 
rover. Present in that address word are three Interrupt bits which 
cause the Prime to perform certain operations as it is storing the 
rover data. 

Due to the complex nature of the Prime's operating system, 
a user's program cannot simply manipulate the GPIB but must call a 
special PRIMOS* system subroutine named TSROVR that was developed 
by M. Potmesil (Reference 5). This routine is an input/output (I/O) 
driver which handles all interactions with the interface board. By 
using T$ROVR the user's access to the GPIB is easily accomplished. 

The software that has been written for the Prime falls 
into three categories. First, the realtime software which processes 
the data from the rover and sends appropriate commands back to it; 
second, the diagnostic programs written to debug the telemetry sys- 
tem and the laser mast itself, and third, the assembler I/O driver 
T$ROVR written by Potmesil. The realtime software is described in 
References 9 and 10. The diagnostic programs are mentioned in 
Section 7.3 and are completely documented in the notebook entitled 

*PRIM0S is the operating system used on the Prime computer. 
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"GPIB," volume 2, In the laboratory. 

This chapter diacuaaea some of the physical properties of 
the GPIB board, some of the more obscure details of the operation 
of T$ROVR, and the functions of several programs which were written 
as diagnostic tools for debugging not only the GPIB itself but the 
entire system. A complete description of the hardware can be found 
in Reference 4. 

7.1 Interrupt Handling 

Upon the start of execution of a user's program on the 
Prime, a call must be made to T$ROVR to Initialize Itself and the 
GPIB. After this initialization, T$ROVR waits for an EOS interrupt 
before making any data available to the user. Therefore it is 
imperative that the telemetry system be transmitting these inter- 
rupts from time to time. Once an EOS has been received, T$ROVR 
starts to fill the first buffer which the user has specified to hold 
the telemetry data. From that point on, every time an EOA interrupt 
is sensed, T$R0VR will start to fill the next section of the buffer 
until the buffer is full. Subsequent EOS interrupts will declare 
the buffer as being full and T$ROVR will start to fill the next 
buffer if it is empty. It is important to note that an EOS can 
occur at any time, and that the occurrence of that EOS is the only 
determining factor for declaring a buffer as being full. 

7.2 VLDAIA. VLSTAT. ITSTAT and Scratch Buffers 


The buffers which the user specifies to be filled by TSROVR 
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oust be referenced In the call to T$ROVR which initializes it. The 
interrupt process of T$ROVR fills two 2048-word buffers in the 
array named VLDATA. Each of these buffers is divided into 32 sec- 
tions, one for each azimuth angle scanned by the laser mast. Each 
section contains 64 words consisting of 32 words of vehicle data 
followed by 32 words of laser data. The layout of each buffer is 
shown in Fig. 7.2.1. 

The array VLSTAT contains status information which is 
stored there concerning each section of VLDATA as that section is 
being filled. The format of this array is shown in Fig. 7.2.2. The 
array ITSTAT contains status information about the GPIB interface 
itself. The information in ITSTAT can be updated by a special call 
to T$ROVR, otherwise it is never changed. The format if ITSTAT is 
shown in Table 7.2.1. 

It should be pointed out that the names assigned to the 
three arrays VLDATA, VLSTAT and ITSTAT used in the user's program 
are not important as long as the conventions for loading the programs 
are followed. These are explained in the documentation of T$ROVR 
(Reference 5). All of the Fortran routines which run on the Prime 
use these names for the three arrays, however. 

The scratch buffer used by TSROVR is needed in order for 
interrupts to be received even if both buffers in VLDATA are full. 

In general, it is bad practice to use this data in any calculations 
involving laser data because it will be constantly changing. If 
both VLDATA buffers are full, however, it is possible to get the 
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VLDATA(l)* 


VLDATA(4096) 


buffer 1 , 
section 1 


buffer 1, 
section 32 

buffer 2» 
section 1 


buffer 2, 
section 32 


\ 


> 


/ 


\ 


> 


vehicle and laser data buffer 1 
(32 sections of 64 words * 

2048 words). 


vehicle and laser data buffer 2 
(32 sections of 64 words * 

2048 words). 


* must be on a Prime memory page boundary 


Fig. 7.2.1 Format of VLDATA array 
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A section of 64 words In VLDATA buffer (one of 32): 


VLOATA (index) 


VLDATA (index+63) 



> 32 words of vehicle data 


> 32 words of laser data 


index * 2048*(buffno-l) + 64*(sectno-l) + 1 

buff no .... buffer number (1 or 2) 

sectno .... section number in one of the two buffers 
(1.2 31, 32) 

Note 

Each received data word is accompanied by an address word. The 
six least significant bits of the address word are used as offset into 
the current 64-word section and therefore determine where the data word 
will be stored within the current section. 


Fig. 7.2.1 (continued) 
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> 




I 

) 

) 


> 


/ 


System and data status , 

data scratch buffer (detailed description 

follows on next page) 


Status register and system time 
at EOA interrupts for VLDATA 
buffer 1 (32 sections of 4 words**) 


Not used 


Status register and system time 
at EOA Interrupts for VLDATA 
buffer 2 (32 sections of 4 words**) 


Not used 


Not used 


* must be on a Prime memory page boundary 


** 4 words per EOA interrupt: 


word 1 
word 2 \ 
word 3 | 
word 4j 


GPIB status register 

Current system time 
(Format given in Fig. 5) 


* 


Fig. 7.T.2 Format of VLSTAT array 



System and data status: 


VLSTAT(l) 


VLSTAT(2) 


VLSTAT(3) 
VLSTAT ( 4 ) 
VLSTAT(5) 

VLSTAT(6l 

VLSTAT(7) 

VLSTAT(8) 


* given as 


System status: 

-1 . . . system Initialized, waiting for EOS interrupt 
to start scanning to VLDATA (data is currently 
received to data scratch buffer, rover is 
stopped) 

0 . . . both VLOATA buffers are full (data is currently 

received to data scratch buffer, rover is 
stopped) 

1 . . . data is currently received to VLDATA buffer 1, 

rover is started 

2 . . . data is currently received to VLDATA buffer 2, 

rover is started 

3 . . . received FIFO overflow while filling VLDATA 

buffer 1, waiting for EOS interrupt to start 
refilling buffer 1 (data is currently received 
to data scratch buffer, rover is stopped) 

4 . . . received FIFO overflow while filling VLDATA 

buffer 2, waiting for EOS interrupt to start 
refilling buffer 2 (data is currently received 
to data scratch buffer, rover is stopped) 

5 . . . received TIMEOUT error, waiting for EOS 

interrupt to start refilling current VLDATA 
buffer (data is currently received to data 
scratch buffer, rover is stopped) 

6 . . . received raw error (no interrupt bits set), 

see Status register in VLSTAT(2), rover 
stopped, interrupts and DMX disabled, data 
not received. 


CP IB Status register during the last interrupt, initialized 
to zero. 

System time at the beginning of the last interrupt, 
initialized to zero. (Format given in Fig. 5) 

Number of TIMEOUT interrupts* 

Nunber of FIFO overflow interrupts* 

Number of EOS interrupts* 


mod 2^ 5 number since system initialized. 


Fic. 7.2.2 (continued) 
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VLSTAT(9) Not used 

VLSTAT(IO) Not used 

VLSTAT(ll) Number of filled (valid) vehicle sections in VLDATA 

buffer 1 (0 . . . empty, 1-32 sections filled) 

VLSTAT( 12) Number of EOV interrupts received while filling 
VLDAT.A buffer 1 

VLSTAT (13) Number of filled (valid) laser sections in VLDATA buffer 
1 (0 . . . empty, 1-32 sections filled) 

VLSTAT(14) Number of EOA interrupts received while filling VLDATA 

buffer 1 


VLSTAT(15) EOS interrupt status of VLDATA buffer 1 


0 . . . EOS not received 

1 ... EOS received, VLDATA buffer 1 is full , 

at this time VLSTAT (11) and VLSTAT(l4) 
should contain 32 


VLSTAT ( 16 ) 1 
to f 
VLSTAT ( 20) J 

VLSTAT (21) 1 
to f 
VLSTAT (30) J 

VLST AT ( 31 ) 1 
to i 
VLSTAT (64) J 

VLSTAT (65) 1 
to } 
VLSTAT ( 1 28 )J 

VLST AT ( 1 29 ) 'l 
to } 
VLSTAT ( 200 )J 


Not used 

Same as VLSTAT(ll) to VLSTAT(20) but apply 
to VLDATA buffer 2 


Not used 


Data scratch buffer, data is stored into this 64-word 
buffer while it cannot be stored into VLDATA buffers 


Not used 


Fig. 7.2.2 (continued) 
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ITSTAT(l) 

Status register 

ITSTAT(2) 

Command register 

ITSTAT(3) 

DMX address register 

ITSTAT (4) 

Vector address and DMX mode register 

ITSTAT(5) 

ID slot register 

ITSTAT(6) 

Total number of Interrupts generated by the Interface 
since last initialize operation or last assign conmand 

ITSTAT(7) 

Number of "Invalid address" interrupts (for TSROVR 
debugging only) 

ITSTAT(8) 

Number of "attempted page-fault" interrupts (for 
TSROVR debugging only) 

ITSTAT (9) 

Run flag: 0 . . . vehicle started 

1 . . . vehicle stopped 

ITSTAT (10) 

VLDATA buffer 1 full flag: 0 . . . buffer empty 

1 . . . buffer full 

ITSTAT(ll) 

VLDATA buffer 2 full flag: 0 . . . buffer empty 

1 . . . buffer full 

ITSTAT (12) 
ITSTAT (13) 
ITSTAT(14) 

System time (minutes) 

System time (seconds) 

System time (ticks, where 1 tick = 1/330 second) 

ITSTAT (15) ) 
to > 

ITSTAT (20) ) 

Not used 


Table 7.2.1 Format of ITSTAT array 
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latest vehicle data from the first part of that buffer due to the 
fact that the same analog and digital data will be stored at any 
particular location in the block of vehicle data* In the case of 
laser data received while both buffers are full, however, the 
user would have no way of knowing which azimuth was being stored 
in the scratch buffer when it was being read. 

7.3 Debugging Aids for the GPIB Interface and Telemetry System 

In addition to the I/O driver T$ROVR, M. Potmesll also 
wrote a number of diagnostic programs that are useful for testing 
the interface between the telemetry system and the Prime. These 
programs are shown in Table 7.3.1. All of the programs in that table 
reside in the User File Directory (UFD) <SYSTEM0>TEST.GPIBS>TEST, 
T$ROVR. There are also other programs, discussed below, which were 
written by the author. These programs are stored on the backup tape 
of the MARS UFD created at the end of the project and are located in 
the UFD named <USERS3>MARS>GRAHAM. Source listings are also in the 
notebook pertaining to the GPIB interface, volume 2. 

The program named #SEND essentially has the same function 
as Potmesil*s except that it tests all possible bit patterns which 
can be written into the command- transmit register on the GPIB inter- 
face. It also prints a message for every 1024 commands which are 
sent. 

The program #SEND.GD can be used to send any of the cur- 
rently implemented commands which the microprocessor of the laser 
mast recognizes. It was written primarily as an aid for testing 
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//START 

//STOP 

//BADKEY 

f/BADBUF 

//STATUS 

#SEND 

//SCAN 


Table 7 


Initializes T$ROVR. 

Stops T$ROVR from receiving data and 
Interrupts from the GPIB. 

Calls T$ROVR with a bad key and 

should generate an error message. 

Tries to Initialize T$ROVR with a bad 
buffer address for VLDATA. Note 
both VLDATA and VLSTAT must be 
located on a page boundary. 

Calls T$ROVR to get the GPIB status 
and prints It. 

Loads the command link register and 
reads it back to verify the 
contents of that register. 

Fully tests T$ROVR in diagnostic mode. 
This program generates simulated 
vehicle and laser data and inter- 
rupts and also demonstrates the 
correct use of T$ROVR as a sub- 
routine called by Fortran prc~rams. 


3.1 CPIB Diagnostic P?:ograms. 


* 
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actual command* sent from the Prime to the rover via the RF command 
link and also served as a reference for the software group when it 
came time for them to send commands in the path-selection and 
navigation routines. 

The program tfRECV.GD is probably the single most powerful 
tool in discovering problems occurring in the telemetry system. 

This program has the capability of displaying any data which T$ROVR 
can store in the user's address space. It will empty the VLDATA 
buffers consecutively and can store any or all of the Incoming data 
from the rover in these buffers as well as the contents of the 
VLSTAT and ITSTAT buffers on disk or magnetic tape for later use. 

In the early stages of the development of a running version of the 
controlling software on the Prime, this disk or magnetic tape data 
base could provide consistent data to that software. The program 
#RECV.GD has several interactive qualities which enable the user to 
selectively empty buffets-, disable emptying buffers entirely, stop 
dumping data to disk and/or tape, and reinitialize T$ROVR even in 
the middle of execution of the program, to mention a few of the 
possibilities. A complete list of commands for the program is con- 
tained in the GPIB notebook mentioned above. 

There is also a MAP mode which will display a matrix of 
laser returns. This display condenses information about all azi- 
muths and elevations at which laser shots occur into one screen 
image. A maximum of eight azimuths (columns) and 12 elevations (rows) 
can be displayed at any one time. The starting row and column of the 
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upper left-hand element In the matrix can be set by the NEnn and 
NAnn commands, respectively. The two numbers which appear at each 
location of the matrix are the identification numbers of the 
detectors which received returns from a given laser shot at the 
elevation and azimuth given by their location in the table. If 
asterisks appear at a location, then no data concerning a laser 
shot at that azimuth and elevation angle was received by the GPIB. 

If a location is blank, this indicates that a missing return 
occurred, i.e., none of the detectors received a return for that 
laser shot. 

The program #POST.GD can be used to read the disk or mag- 
netic tape files created by //RECV.GD and provides for displaying 
any of the data which T$ROVR stored in the VLDATA, VLSTAT and ITSTAT 
buffers in a manner similar to //RECV.GD except that the data being 
displayed could have been received minutes or hours before. It 
features the same MAP mode as #RECV.GD and the commands which it 
accepts are also documented in the notebook along with the commands 
for #REC V.GDt 

The programs in the UFD<USERS3>MARS>GRAHAM are of more 
interest to the hardware development group since they provide more 
data on the number of timeouts, total number of interrupts, et 
cetera, than the control-oriented software group would in general 
be interested in. 

Several files in the UFD also contain code for the M6800 
microprocessor which enable it to operate the telemetry transmitter 
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and sand dummy data down to the Prime. Some of these are listed in 
Table 7.3.2. These programs can be downloaded into the micropro- 
cessor from the Prime by running the program *DNLOAD and then con- 
necting the microprocessor to the user's terminal as described In 
the notebook pertaining to the microprocessor (see Chapter 8). 


56 






XMIT.GD Sends data from 1024 laser shots and 1024 vehicle 

words , and fills an entire VLDATA buffer. 

The address and data words are the same 
except for interrupt bits set for EOA, EOV 
and EOS interrupts. Data and address words 
Increment from zero to $7FF. 

XMIT.N0E0V Same as XMIT.GD except doesn’t generate EOV 

interrupts. This program shows the dramatic 
effect EOV interrupts have on the system's 
performance as far as slowing it down. 

XMIT.N0E0A Same as XMIT.GD except doesn't generate EOV or EO/» 

interrupts. 

XMIT.NOINT Same as XMIT.GD except doesn't generate any 

interrupts after the first EOS interrupt. 


Table 7.3 


Microprocessor Transmitter Programs. 


PART 8 


LABORATORY REFERENCE MATERIAL 

There are several notebooks In the lab which contain 
Information about all parts of the systems controlling the rover. 
Each is labeled , making it easy to find Information on any one 
of them. For example, the documentation on the GPIB Interface 
takes up two such notebooks. Volume 1 containing mostly hardware 
specifications and Volume 2 containing mostly software specifica- 
tions and listings. The titles of these notebooks are shown in 
Table 8.0.1. 
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TITLE 

MICRO 


PROPULSION/ 

STEERING 


TELEMETRY 


GPIB, Vol. 1 


GPIB, Vol 2 


MAST 


REALTIME 

SOFTWARE 


CONTENTS 

Contains documentation on the microprocessor board 
itself along with the instruction manuals 
supplied by Motorola and listings of all 
proerams which were written for the M6800 for 
use by the rover project. Also has instruc- 
tions for downloading programs from the Prime 
computer to the microprocessor. 

Contains the hardware description of the motor speed 
controller board as designed by both Turner 
and Bogdan, a copy of Turner's masters thesis, 
and lists of signals which the microprocessor 
uses and generates when it controls the vehicle. 

Contains the hardware description of the telemetry 
transmitter and analog multiplexor boards as 
well as the final circuit diagrams of the 
command link. 

Contains the hardware description of the circuitry 
on the GPIB which was designed by Donaldson. 

All modifications are noted. 

Contains the listings and descriptions of programs 
which exercise the GPIB interface as well as 
those for use in debugging the telemetry data 
link. 

Contains the hardware description of the mast elec- 
tronics including the laser detector elec- 
tronics . 

Contains documentation on the realtine programs which 
run on the Prime, the locations of mag tape 
backups for the Mars UFD, etc. 


Table 8.0.1 Laboratory Notebooks 
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